Controlled data network error recovery

ABSTRACT

A method, a system and network nodes using indication of possible duplicates (IPD) of units, so that these units can be handled differently than other units. The unit is indicated to be a possible duplicate to the entity to which it is resent because no response was received from the entity it was sent to.

FIELD OF THE INVENTION

[0001] The present invention relates to a method and equipment fortransmission both in fixed networks and mobile networks, e.g., GPRSback-bone networks and W-CDMA backbone networks.

BACKGROUND OF THE INVENTION

[0002] In packet-switched network systems a mechanism called a slidingwindow is used to control the flow of packets across a data link. Aseach packet is transmitted, an upper window edge UWE is incremented byunity. Similarly, as each packet is acknowledged, a lower window edgeLWE is incremented by unity/acknowledged packet. The sending of newpackets is stopped, when the difference between the UWE and LWE becomesequal to the size of the send window. Then the sending node retries tosend these sent but not acknowledged packets to the same receiving node.The sending node is a packet data transmission node, which can generatepackets and transfer packets other nodes have generated. If thereceiving node then receives the resent packet(s) correctly, it candetermine if a received packet is a valid transmitted packet or aduplicate in this simple case where only two nodes are involved.Determining is usually done by comparing the sequence number of thereceived packet with the sequence numbers of successfully deliveredpackets. Normally the sequence number is inserted into each packet bythe sending node.

[0003] A problem with the current solution arises when the receivingnode is “dead” for some time. In real live environments several kinds ofnetwork failures may occur or data transmitting elements may go down dueto a network element failure. When that happens, the resending ofpackets to the same node also fails. Then the sending node reroutes thetransmission and sends the packet (or packets) to another node via whichit can route packets to the end system. However, it is possible that thefirst node received that packet (or packets) and has sent it (them)forward before the failure. The sending node does not know when thefailure happened. It does not know whether the failure happened when thepacket was sent first time or when the packet was received or whetheronly the response (acknowledgement) got lost. Therefore, duplicates aresent to the end system. The end system has to check for every packet itreceives whether it is a duplicate, for example in order not to bill acustomer twice. One possible way to solve this problem is not to sendduplicates, but then important information may be lost.

[0004] The same problems are encountered in systems using frames,packets or any other resendable units. A frame usually comprises aprotocol-related header and payload data. An empty frame is a frame withno payload data.

BRIEF DESCRIPTION OF THE INVENTION

[0005] The object of the invention is to overcome the problems statedabove. The object of the invention is achieved with a method, a systemand network nodes which are characterized by what is disclosed in theindependent claims. The preferred embodiments of the invention are setforth in the dependent claims.

[0006] The invention is based on indicating that a unit is possibly aduplicate of another unit which is resent because no response wasreceived from the entity it was sent to.

[0007] The advantage of the invention is that possible duplicates areindicated, so that the system can handle these units differently thanother units. For example, the end system or some other system does notneed to check every unit to see whether it is a duplicate. Thisminimizes the load in the system.

[0008] In one embodiment of the invention the sending entity is alsoindicated. The advantage of this embodiment is that it is possible touse one and the same receiving entity as an intermediate storage fordifferent sending entities, since the units can be identified by sendingunit identity and sequence number. Therefore, they cannot be mixed upwith other units having the same sequence number in the receiving entityand the network operation. A further advantage is that networkmaintenance does not need to make sure that two sending entities do notuse the same receiving entity as the intermediate storage.

[0009] In one embodiment of the invention, the unit indicated to be apossible duplicate unit is sent forward from the second entity onlyafter the sender has given instructions to send. Before givinginstructions, the sender has checked from the first entity whether ithas got the packet. The advantage of this embodiment is that theduplicate unit is not sent in vain in the network and thus the networkload is minimized. Another advantage of this embodiment is that there isno risk of getting duplicates of units because of a communicationfailure between the sending node and receiving entity. Yet anotheradvantage of this embodiment is that the load caused by cross-checkingof duplicates in a border area (e.g., a month has changed in the billingsystem) can be avoided.

[0010] In one embodiment of the invention, the possibility that a unitis a duplicate is checked in the end system only when the received unithas been indicated to be a possible duplicate. The advantage of thisembodiment is that the duplicate checking is not done in vain and theend systems can be made more simple. Besides, the units arrive at thereceiving end in such a manner that it is possible to re-establish theirorder. Brief description of the figures

[0011] In the following, the invention will be described in greaterdetail by means of preferred embodiments and with reference to theaccompanying drawings, in which

[0012]FIG. 1 is a flow chart illustrating the functionality of a sendingentity in the first preferred embodiment;

[0013]FIG. 2 is a flow chart illustrating the functionality of areceiving entity in the first preferred embodiment;

[0014]FIG. 3 is a flow chart illustrating the functionality of a sendingentity in the second preferred embodiment;

[0015]FIG. 4 is a flow chart illustrating the functionality of an endsystem according to the invention; and

[0016]FIG. 5 illustrates one example of a system according to theinvention.

DETAILED DESCRIPTION OF THE INVENTION

[0017] The present invention is suitable for use both in fixedcommunications systems and in mobile communications systems. Theinvention is particularly suitable for use in implementing the GeneralPacket Radio Service (GPRS) in the pan-European digital mobilecommunications system GSM (Global System for Mobile Communications) orcorresponding mobile communications systems, such as DCS1800 and PCS(Personal Communication System). The invention is also suitable forthird-generation mobile systems, such as Universal Mobile CommunicationSystem (UMTS) and Future Public Land Mobile Telecommunication System(FPLMTS) later renamed as IMT2000 (International MobileTelecommunication 2000), which at present are being developed. Thepresent invention may be used e.g., in handovers when frames are alsoresent to the target network entity.

[0018] The present invention can be implemented in existing networknodes. They all have processors and memory with which the inventivefunctionality described below may be implemented. In some embodiments,some extra memory may be needed. The functions described below may belocated in one network element or some of them may be in one element andthe others in other elements regardless of how they are located in theexamples used to illustrate the invention. Transmitting nodes are alsocalled intermediate nodes. Since the sending illustrated e.g., in FIGS.1 to 4 may be an internal exchange of information, nodes are also calledentities. The term ‘node’ as used herein should be understood togenerally refer to any network element or functionality which handlesthe units.

[0019] In the following description, the term ‘packet’ is used for thesake of clarity. The term ‘packet’ should be understood to also mean anyother resendable unit, e.g., a frame. Frames are used e.g., in the radiolink protocol. In the following, the invention is described using twointermediate entities for the sake of clarity yet without limiting theinvention to that kind of solutions. It is even possible to implementthe invention in systems where only one receiving node exists and thesending node cannot reroute resendable units when it has enough memory.The preferable embodiments have, however, at least two alternativedirections to send these resendable units from the sending node.

[0020] In the following description, it is assumed for the sake ofclarity, that a packet generating node has difficulty with a first nodevia which it tries to send one packet to an exit node, but it has nodifficulty with a second node. The end system, e.g., a billing system,is described here to be one entity, although the end system may compriseseveral different entities. The structure of the end system is notimportant to the invention. It is also assumed, for the sake of clarity,that only one packet is sent. A person skilled in the art knows how todeal with a plurality of packets being possible duplicates, that is, howto handle e.g., a window whose size is bigger than one.

[0021]FIG. 1 illustrates the functionality of a sending node (entity) inthe first preferred embodiment of the present invention. The sendingnode can be a packet generating node (entity) or an intermediate nodesending the packet further ahead. In step 101, the node sends a packetP1 to an entity 1. The entity 1 may be the primary peer. The packet P1has a sequence number by which it can be identified within a windowsize. The window size must be smaller than the maximum sequence numberin order to identify the packet properly (unless the window size isone). The node discovers in step 102 that no response is received. Instep 103, it tries to resend the packet P1 to the entity 1, but fails.In another embodiment, an IPD is added to the packet P1 before resendingit in step 103. The IPD is an indication indicating a possible duplicateof the packet P1. Resend means here the same as a retry send. Resend isrepeated a predefined number of times after time-outs of given lengths.Then the node stores into its memory the sequence number SN of thepacket P1 and the entity 1 in step 104. This is how it knows where itsent the packet P1 without receiving a response. Then, in step 105, thenode picks from its priority list an entity whose priority is smallerbut closest to the priority of the entity 1. Picking means that thesending node selects according to predetermined rules the next entity(or its address) to which it will try to send next. Here, that entity isthe entity 2. Next, the node stores in step 106 into its memory theentity 2 so that it knows that it has first tried to send the packet P1to the entity 1 and after that to the entity 2. Then it adds an IPD tothe packet P1 in step 107. Next, the node sends in step 108 the packetP1 to the entity 2 and receives a positive response from it in step 109.A positive response means here an acknowledgement of receiving thepacket P1.

[0022] If a positive response is not received from the entity 2, thenode can repeat the steps 105 to 109 until a positive response isreceived. A positive response means that the packet P1 was receivedsuccessfully. As long as the entity 1 is “dead”, the packets may be sentvia the entity 2.

[0023] Then in step 110 the node notices that the entity 1 is again“alive” and that packets can be sent to it again. How the node noticesthat the entity 1 is alive is described later in more detail withalternative examples with reference to FIG. 5. In step 111, the nodechecks from its memory, whether there are packets sent to the entity 1,which may have a duplicate. That is, it checks e.g., whether there arepackets in its buffer for unconfirmed packets. If there are no packets,the node continues normally by sending new packets either via the entity1 or entity 2 depending of the configuration. In this example, theserving node finds out that the packet P1 is a possible duplicate andsends a test packet to the entity 1 in step 112. This test packet is anempty packet with the sequence number of P1.

[0024] After that, the node receives a response from the entity 1 andchecks in step 113 if the response is ok. If the response is ok, theentity 1 never got the original packet P1 or did not succeed in sendingit. The response is ok, if it is e.g., a request accepted message.Therefore, there are no duplicates and the node sends in step 114 to theentity 2 a message indicating that the entity 2 can release the packetP1. In other words, the node allows the entity 2 to send the packet P1ahead. If in step 113 the response indicates that the entity 1 hasalready received that packet, the node sends in step 115 to the entity 2a message indicating that the entity 2 can delete the packet P1 from itsmemory. A cancel message can also be used for the same purpose. In otherwords, the node 2 is not allowed to send the packet P1 ahead. The packetP1 is identified by the sequence number in the message sent either instep 114 or 115. It is also possible to use an identification of theentity 1 in the messages sent in steps 108, 114 and 115. The messagewhich indicates that the response is not ok may be a request alreadyfulfilled, for example. The sending of new packets to the entity 1 ispreferably done after instructions on all unconfirmed packets have beensent.

[0025] In some other embodiments, instead of the storing done in steps104 and 105, buffering can be used, but then there is a risk of losinginformation due to a failure.

[0026] In some other embodiments, the whole packet P1 may be saved instep 104 and sent as a test packet in step 112. It is also possible tosave the packet only in the entity 2 and, when sending the test packet,the sending node first asks the entity 2 to send a copy of it. Dependingon the application in these embodiments, the message sent in step 114may only allow the release of the packets which were not sent as testpackets and the test packets are deleted because their sequence numberswere not in the release message.

[0027] If the resend does not fail in step 103, further packets are sentnormally to the entity 1.

[0028]FIG. 2 illustrates the functionality of a packet receiving entityin the first preferred embodiment. The receiving entity is assumed to bean intermediate entity. The receiving entity RE receives in step 201 apacket P1 from a sending entity SE. The RE checks in step 202 whetherthere is an IPD (indication of possible duplicate) in the packet P1. Ifthere is, the RE stores in step 203 the packet P1 in order to wait forinstructions from the SE. It may also store the packet P1 with theinformation that it received it from the SE and/or an identification ofthe first entity if indicated by the SE. In step 204, the RE waits forinstructions. During this waiting, it may transmit other packetsnormally. In step 205, the RE receives instructions concerning thepacket P1 from the SE. (It identifies the packet P1 e.g., by thesequence number.) In step 206, it checks if the instruction indicates adelete or a cancel. If it is a cancelling or deleting instruction, theRE deletes from its memory the packet P1 in step 207. If the instructiondid not indicate a delete/cancel but a release, the RE sends the packetP1 ahead normally in step 208. In the first preferred embodiment, thepacket P1 still has the IPD with the added information that it isreleased by an instruction from the sending entity, so that e.g., theend system may still check whether it has got it earlier, but the otherintermediate nodes do not store it to wait instructions since it hasthis added information with the IPD. In some other embodiments, the REmay take the IPD away from the packet. Then no other checking ofduplicates is done in vain. In embodiments which use maximum storingtime before delivery, it is very advantageous to have the IPD in thepacket, because the packet may be released because the length of thestoring time of the packet reaches the maximum storing time.

[0029] If there is no IPD in step 202, the RE sends the packet P1 aheadnormally in step 208.

[0030]FIG. 3 illustrates the functionality of a sending node (entity) inthe second preferred embodiment of the present invention. In step 301,the node sends a packet P1 to an entity 1. The node discovers in step302 that no response has been received. Then, in step 303 the node picksfrom its address list an address of the next entity, entity 2. Then itadds an IPD (an indication indicating possible duplicate of the packetP1) to the packet P1 in step 304 and sends in step 305 the packet P1 tothe entity 2. In some other embodiments, step 303 may be similar to step105 of FIG. 1 and/or step 103 of FIG. 1 may be done between steps 302and 303. It is assumed that after step 305 a positive acknowledgement(response) is received. If not, then the steps 303 to 305 are repeateduntil a positive response is received.

[0031] The packet P1 is sent ahead to the intermediate entities (nodes)in the second preferred embodiment until it reaches the end system. FIG.4 illustrates the functionality of an end system in the second preferredembodiment of the invention. In embodiments having only one receivingnode, the functionality described in FIG. 4 may be implemented into it.When an embodiment related to the first embodiment of the invention isused, where the receiving entity does not remove the IPD when sending apacket forward, the end system does not need to function as illustratedhere in FIG. 4.

[0032] Referring to FIG. 4, the end system ES receives a packet P1 instep 401 and checks in step 402 whether there is an IPD (indication ofpossible duplicate) in the packet P1. If there is, it goes in step 403through all the packets it has received in order to find out whether ithas already received this packet P1. If the ES finds out in step 404that the packet P1 is a duplicate, it deletes in step 405 the packet P1with the IPD it received in step 401. If the ES finds out in step 404that it has not received the packet P1, in other words, the packet P1 isnot a duplicate, it saves in step 406 the packet P1 or at least enoughinformation in order to do a duplicate check, if needed. Then it sendsthe packet P1 or its information for further processing according tonormal procedures depending on the application. If in step 402 no IPD isfound, the ES continues from step 406.

[0033] The first preferred embodiment is very well suited forapplications where the order of packets in the end system is notimportant, like billing systems or email. Its advantage is that thenetwork is not loaded unnecessarily by sending duplicates through thewhole network. The second preferred embodiment may also be used insystems where the order of the packets is of some importance, like inconnection with still pictures or photos.

[0034] The steps have not been set out in absolute time sequence inFIGS. 1, 2, 3 and 4. Some of the steps described above may take placesimultaneously or in a different order or some of the steps can beskipped 30 over, e.g., steps 110 to 115. It is also possible to add newsteps not shown in the figures, for example in FIG. 1 between steps 109and 110 new packets can normally be sent to the entity 2 without markingthem as duplicates. It is also possible to check before step 203 in FIG.2 whether the IPD includes additional information that the packet isreleased by an instruction from the sending entity, and if there is, theprocess continues from step 208, otherwise from step 203. Anotherpossibility is to combine steps in the figures when making a newembodiment. For example, it is possible to further process the packet instep 406 by taking the IPD away and sending the packet ahead. It isessential that the possibility of the packet being a duplicate isindicated. The indication can be done e.g., by adding it to the packetheader or to the payload or to the file name when file protocols areused or by sending a message indicating that the following packet is apossible duplicate. The indication may also be in another frame. It isalso possible to indicate the duplicate in the message the unit is sentwith, e.g., ‘send packet’ means that the packet is not a duplicatewhereas ‘send possibly duplicated packet’ indicates a possibleduplicate. The indication may even go via another link. It is notimportant how this indication is done, the essential thing is that it isdone. The messages may include more information than what is statedabove. The names of the messages may differ from those set out above orthe indications or the instructions according to the invention may besent in other messages than those stated above. For example, ‘delete’may be ‘cancel’ or the IPD may be called a mark of a potential/possibleduplicate MPD.

[0035] In the above, storing means that the information is stored sothat it is not lost e.g., during a restart. In other words, it is storedto a nonvolatile memory. The information may be stored in the sendingunit and/or any other active entity with which the sending unit has aconnection. That entity may be the receiving entity or a totallydifferent entity. In the above, a sequence number is used to identifythe packet. Other identification may also be used. In a preferredembodiment, the sending unit also indicates the first receiving entitywhen it indicates a possible duplicate. This way, the receiving entityknows whose possible duplicates it has. This is very advantageous sincethe same intermediate entity can store possible duplicates first sent todifferent nodes and yet identify them properly. It is possible toindicate the sending node and use this information for identifyingpurposes.

[0036]FIG. 5 illustrates one example of a system according to theinvention. For the sake of clarity, FIG. 5 has only one packetgenerating node PGN1, although it is possible to have a plurality ofPGNs. The PGN1 has, in this illustrative example, three links: Link 1 topacket receiving node PRN1, Link 2 to packet receiving node PRN2 andLink 3 to packet receiving node PRN3. The PGN1 can send packets to theend system ES via all the packet receiving nodes. The packet receivingnodes are intermediate entities. The packets are sent ahead until theyreach the end system ES. Although not illustrated in FIG. 5, there maybe any number of PRNs between e.g., PRN1 and ES. If the systemillustrated in FIG. 5 is a GPRS billing system, then the PGN1 may be aserving GPRS support node SGSN or a GPRS gateway support node GGSN, andpacket receiving nodes may be different nodes which have a charginggateway functionality CGF. So they may also be called charging gatewaynodes. The end system ES may be a billing system. The GPRS billingsystem with one charging gateway is described in more detail in FinnishPatent 102232. This patent is incorporated herein by reference.

[0037] Some alternative examples are described below in more detail withreference to FIG. 5. The abbreviations used are:

[0038] BS=Billing System

[0039] CDMA=Code Division Multiple Access

[0040] CDR=Call Detail Record

[0041] CGF=Charging Gateway Function

[0042] IMSI=International Mobile Subscriber Identity

[0043] GPRS=General Packet Radio Service

[0044] NE=Network Element

[0045] O&M=Operations and Maintenance

[0046] PDP=Packet Data Protocol

[0047] W-CDMA=Wideband CDMA

[0048] PGN=Packet Generating Node

[0049] PRN=Packet Receiving Node

[0050] ES=End System

[0051] The application areas in the following examples are environmentswhere it is not absolutely crucial that the packet sent from the PGNs tothe ES arrives in exactly the original order, but where it is usefulthat the packet contents are not lost even in abnormal network linkfailure situations or NE failure situations. For example, charging datacollection in packet-data based telecommunications systems is a verylikely application area. One example of this kind of an environment isGPRS charging. In GPRS, the SGSNs and GGSNs are PGNs, the CGFs are thePRNs and the BS is the ES. Each packet transmitted between a PGN and PRNmay contain one or more CDRs as payload inside the packet frame.

[0052]FIG. 5 is an architectural example of a chain of network elements,where the PGN1 sends packets towards the ES via either the PRN1, PRN2 orPRN3. The PRN1 is here assumed to be the primary choice (priority 1 PRNpeer name configured to its PRN address list as the first place toattempt packet sending). The packet flow is assumed to be as follows:Packet Generating Node(s)→ Packet Receiving Nodes→ End System.

[0053] Both the packet receiving node and the end system have a massmemory for packets.

[0054] The initial assumptions are as follows:

[0055] The topmost protocol in the communication software stack thattransfers packets between the PGN and the PRNs is assumed to be aRequest-Response type message-based protocol.

[0056] The packet send window size per each link from the packetgenerating node is smaller than the maximum sequence number (that isallowed to run over back to 0 and increase again per each packet).

[0057] In most telecommunication systems, such as those given in theseexamples, the mass storage devices can be assumed to maintain theirinformation even when the network element goes down due to a softwarefailure or lack of processing capacity in relation to the traffic load.

[0058] Possible problems which are solved here in these examples are asfollows:

[0059] Duplicated information (e.g., packets containing CDRs) may begenerated when traffic is redirected and the packet generating node doesnot surely know if the redirected packets were already successfullytransmitted to the packet receiving node 1 or not.

[0060] A network operator is governed by the laws and administration ofthe country within which it operates. The operators are audited byofficials. An operator might be subjected to penalties or even lose itsnetwork operator licence if it generated too big bills to itssubscribers, because of duplicated CDR information.

[0061] Also, it could lose its credibility among its customers if someuser data packets or CDRs related to them were either duplicated orlost.

[0062] On the other hand, operators do not want to unnecessarily losemoney, so they do not want to unnecessarily cancel packets containingCDRs unless they are 100% sure the packets are duplicates.

Example A

[0063] In this example, sequence numbers are used for packets (typicallyin the frame of the packets) in each link from the packet generatingnode (PGN) to the packet receiving node (PRN). The sequence numbers areincremented by one and roll over again to 0 after e.g., 65535, but theimportant thing is that the maximum sequence number is bigger than themaximum receive window size of a PRN.

[0064] The packets are redirected (marked with a potential duplicateflag) to a parallel node PRN2 (or PRN3 if PRN2 is not available for somereason, etc.) in case the PRN1 fails. The PGN1 also sends to the PRN2identification information of the PGN1, so that the PRN2 can identifythese packets. This is necessary since the PRN2 can have packets markedwith a potential duplicate flag also from other PGNs with the samesequence numbers.

[0065] The PRNs keep the packets marked potentially duplicate in memorybuffers or a mass storage so that the information of their origin (PGN1or PGN2 or other PGN) can also be associated with the packets. This isnecessary since the sequence numbers of packets are unique at a certainmoment only in each PGN-PRN communication link, but not necessarily atthe same time in the whole network.

[0066] Packet generating nodes keep track per each packet receivingnode, i.e. per each link, of sequence numbers of packets whosesuccessful transmission is not certain. If the PGN1 fails to send apacket to the PRN1 and also fails in sending a possible duplicate of thepacket to the PRN2, then the PGN1 tries to send the possible duplicateof the packet to another PRN, e.g., PRN3. However, there is no need tokeep track of sequence numbers of the possible duplicates which the PGNtried to send to PRN2 per this link, since link-specific information ismaintained on these packets in the link to the PRN1. It is, however,possible to add to the information relating to the link PRN1 that thesepackets were also sent to the PRN2 and PRN3.

[0067] The PGNs sense when their peer nodes, PRNs, come alive again.Either the PGNs send ‘keep alive’ messages to the PRNs at appropriateintervals (getting echoing response back from the PRNs if the PRNs arealive and working ok), or the PRNs (and possibly other nodes too) caninform their peer nodes (configured communication partners) always whenthey come alive after being non-working. Also, when a node is stoppingworking, e.g., when the operator wants to stop it to make a softwareupdate, the node can inform its peer nodes that it is going down andshould not receive packets any more until it announces it has becomealive again.

[0068] The PGNs sense what information the previously collapsed node hadbeen able to process successfully.

[0069] The PGNs inform the secondary receiving node which packets it cansend forward towards the end system.

[0070] It might also occur that at some time the PGN node goes down andits volatile memory contents are destroyed, including the buffer forsequence numbers of packets whose reception by e.g., a PRN1 was possiblynot successful and which have been sent (marked as potential duplicates)to a PRN2 to wait for a later decision by the PGN. In this case, thepotential duplicates might stay very long at the PRN2. Therefore, it isrecommended that the PRNs either have a long enough time-out to cancelsuch packets themselves or the operator has tools for gettinginformation about this kind of a situation and a tool to delete suchlong-waiting potential duplicates by an O&M operation from a PRN2.Another alternative is to finally allow the sending of the packets(e.g., marked as potential duplicates) towards the ES.

Example B

[0071] Similar as example A but there is a different sensing method forfinding out whether the PRN1 (who had gone down and then become aliveagain) has already successfully handled a packet (sent by the PGN1) witha certain a sequence number. Here, the PGN1 would send a normal wholepacket again to the PRN1, the only difference being that now the packetis marked a potential duplicate. This requires that the intermediatestorage for whole packets resides either in the PGN1, or the whole(potentially duplicated) packet should first be fetched from the PRN2(where it has been waiting in an intermediate storage for a finaldecision whether it can be sent to the ES). The PGN1 could ask the PRN2to give a specific potentially duplicated packet back by referring tothe sequence number of the packet, and after getting back thepotentially duplicated packet from the PRN2, it could be resent to thePRN1. After that the PRN1 would give a response to the PGN1 (on whetherit has already done the sending, i.e. processed successfully that packetor whether it got the packet “for the first time”). Then there are twopossible submechanisms in case it was “new” to the PRN1: B1) the PRN1processes such a packet towards the ES and informs the PGN1 and the PGN1cancels the potentially duplicated packet stored as a backup in the PRN2(or even the PGN1), or B2) the PRN1 keeps potentially duplicated packetsin its intermediate memory until the PGN1 makes the selecting commands(to cancel the packet in the PRN1 and release towards the ES thepotentially duplicated packet stored in the PRN2, or vice versa).

[0072] Advantages of the examples

[0073] One advantage is an improved performance in the receiving endsystem, since either it has to do a check for duplicated packets(containing e.g., CDRs) for only the very small minority of packets thathave been produced in an abnormal case of a network node or link failureand marked as potential duplicates or no packets produced are duplicatedin the PGN-PRN interface even in abnormal node or link failure events.

[0074] Another advantage is that reliability increases as regards theinformation contents received.

[0075] Yet another advantage is the reduction of possible manual-errorrecovery procedures.

[0076] The examples presented here do not require that the receivewindow sizes of the PRN in a network are the same, so the O&M eventsthat configure the window size are easier to produce in practice, sinceall the receive window sizes of the PRNs need not be updatedsimultaneously.

[0077] It is possible to use as an intermediate storage for differentPGNs one and the same PRN, since the packets are identified at leastwith the PGN and sequence number. Therefore, they are not mixed withother packets in the PRN and the O&M does not need to make sure that twoPGNs do not use the same PRN as the intermediate storage.

[0078] Important Features described in the examples are:

[0079] 1) The two sensing methods presented here in examples A and Bthat the PGN can use to find out whether the PRN has successfullyreceived and processed the packets that it received before the Link 1 orthe PRN became malfunctioning.

[0080] 2) The buffering of the sequence numbers of packets sent from thePGN to the PRN1 associated with the not-successfully-confirmed packetssent by the PGN1. This buffer is maintained in each PGN for each PRNthat the PGN is allowed to be connected to.

[0081] 3) The buffering of the sequence numbers of possibly duplicatedpackets sent to a PRN2 to wait for a later decision (Cancel or Release)by the PGN1.

[0082] 4) The similar redundancy method, but with the difference thatthe buffers for potential duplicates for each PGN1→ PRNx reside in thePGN1 itself.

[0083] 5) The idea of marking (e.g., to packet frames) the potentialduplicates, allowing them to be handled differently than the otherpackets (e.g., to wait in some node for final confirmation on whetherthey are allowed to be sent to the ES or whether the packets should becancelled, i.e. deleted). This is the only essential feature for thisinvention.

[0084] 6) The idea of identifying the packets in the intermediate PRN byusing the identification of the PGN and a sequence number.

[0085] The accompanying drawings and the description pertaining to themare only intended to illustrate the present invention. Differentvariations and modifications to the invention will be apparent to thoseskilled in the art, without departing from the scope and spirit of theinvention defined in the appended claims.

What is claimed is:
 1. A method in a telecommunications system where asending entity may send units to a first receiving entity, the methodcomprising the steps of: sending a unit to the first receiving entity;receiving no response from said first receiving entity; and indicating apossible duplication of said unit when resending it.
 2. The method ofclaim 1, further comprising the step of also indicating the sendingentity when indicating said possible duplication.
 3. The method of claim1 wherein the possible duplicate is indicated in the unit when resendingsaid unit to the second receiving entity.
 4. The method of claim 3,further comprising the steps of: noticing that the first receivingentity is operating; checking whether the first receiving entityreceived said unit; and sending a release message to the secondreceiving entity when said unit was not received in the first receivingentity; or sending a cancel message to the second receiving entity whensaid unit was received in the first receiving entity.
 5. The method ofclaim 3, further comprising the steps of: noticing that the firstreceiving entity is operating; checking whether the first receivingentity received said unit by resending said unit; and sending a releasemessage or a cancel message to the second receiving entity when saidunit was not received in the first receiving entity; or sending a cancelmessage to the second receiving entity when said unit was received inthe first receiving entity.
 6. The method of claim 4, further comprisingthe steps of: receiving said unit in the second receiving entity;storing said unit in response to said indication; and sending said unitin response to said release message from the second receiving entitytowards its destiny; or deleting said unit in response to said cancelmessage.
 7. The method of claim 1, further comprising the steps of:receiving said unit in its end system; checking only in response to saidindication whether the unit is a duplicate.
 8. The method of claim 1,further comprising the step of indicating the possible duplication byadding said indication to the unit before resending it.
 9. A method in atelecommunications system where a sending entity may send units to afirst receiving entity, the method comprising the steps of: sending aunit to the first receiving entity; receiving no response from saidfirst receiving entity; indicating a possible duplication of said unitwhen resending it; receiving said unit in its end system; and checkingonly in response to said indication whether the unit is a duplicate. 10.A method in a telecommunications system where a sending entity may sendunits to a first and a second receiving entity, the method comprisingthe steps of: sending a unit to the first receiving entity; receiving noresponse from said first receiving entity; indicating a possibleduplication of said unit when resending it to the second receivingentity; storing, in the second receiving entity, said unit in responseto said indication; noticing that the first receiving entity isoperating; checking whether the first receiving entity received saidunit; sending a release message to the second receiving entity when saidunit was not received in the first receiving entity; sending said unitin response to said release message from the second receiving entitytowards its destiny; or sending a cancel message to the second receivingentity when said unit was received in the first receiving entity; anddeleting said unit in response to said cancel message.
 11. Atransmission system comprising at least one receiving entity, and asending entity being arranged, when not receiving a response from afirst receiving entity to which it sent a unit, to indicate a possibleduplication of said unit when resending it.
 12. The system of claim 11,wherein said sending entity is further arranged to indicate also thesending entity when indicating said possible duplication.
 13. The systemof claim 11 wherein the sending entity is arranged to indicate saidpossible duplication when resending said unit to a second receivingentity.
 14. The system of claim 13 wherein the receiving entity isarranged to check from a received unit whether it includes saidindication and in response to said indication to wait for instructionson how to handle said unit.
 15. The system of claim 11 wherein thereceiving entity is arranged to check from a received unit whether itincludes said indication and in response to said indication to wait forinstructions on how to handle said unit.
 16. The system of claim 11,further comprising an end system which is arranged to check from areceived unit whether it includes said indication and only in responseto said indication to check whether said unit is a duplicate.
 17. Anetwork node which is adapted to be a sending entity in a network, whichnode is arranged to send an unit to a first receiving entity and whennot receiving a response from the first entity to which it sent a unit,to indicate that said unit is a possible duplication when resending saidunit.
 18. The network node of claim 17 being further arranged toindicate the sending entity when indicating said possible duplication.19. The network node of claim 17 being further arranged to indicate saidpossible duplication when resending said unit to another entity.
 20. Thenetwork node of claim 19 being further arranged to have a priority listof entities to which it may send units and to send the unit to theentity having the next lowest priority.
 21. A network node which isadapted to be a part of an end system in a network, wherein the networknode is arranged to check whether the unit is a duplicate only inresponse to receiving a unit having an indication indicating a possibleduplication of said unit.
 22. A network node which is adapted to be anintermediate node in a network, wherein the network node is arranged tocheck when receiving a unit whether it is indicated to be a possibleduplication of said unit and, in response to said indication, to waitfor instructions on how to handle said unit.